resultTransformer and resultComparator
#446
Conversation
| @@ -249,7 +273,10 @@ export class QueryManager { | |||
| ], | |||
| }); | |||
|
|
|||
| return result; | |||
| // data is optional in GraphQLResult, but not ApolloQueryResult. | |||
| const apolloResult = {data: result.data}; | |||
There was a problem hiding this comment.
It's not clear to me why TypeScript missed this previously (mutate has a return type of Promise<ApolloQueryResult>, and was previously resolving this promise with a GraphQLResult)
There was a problem hiding this comment.
That's probably because GraphQLResult is the same thing as an ApolloQueryResult but with an extra field tacked on.
There was a problem hiding this comment.
The data property is optional in GraphQLResult, but required in ApolloQueryResult
Argument of type 'GraphQLResult' is not assignable to parameter of type '{ data: any; }'.
Property 'data' is optional in type 'GraphQLResult' but required in type '{ data: any; }'.
There was a problem hiding this comment.
Lemme bump this to just cast the value rather than constructing a new object
nevir
force-pushed
the
result-transformation
branch
3 times, most recently
from
5caf812 to
de0f6a6
Compare
Is there ever a good reason to mutate it? I guess just to avoid cloning overhead? |
Yeah, I really worry about cloning the entire graph every time anything changes in the selection set |
igrayson
force-pushed
the
result-transformation
branch
from
de0f6a6 to
08e9367
Compare
|
Hmm, AFAIK @igrayson did sign the CLA |
|
Any feedback on this? |
|
This looks fine to me! Sorry for taking a long time to look at it. If you rebase on top of current master I will merge it. |
nevir
force-pushed
the
result-transformation
branch
from
39d798f to
9fc6bc0
Compare
|
@stubailo rebased! |
|
@stubailo ping again on this :P |
|
@stubailo another ping :> |
You can provide a `resultTransformer` when configuring `ApolloClient` to be able to modify query results immediately before they are returned to the application. Generally, transformers should avoid mutations of their input, as it will bust Apollo's result equality comparsion (and cause unnecessary re-renders). For cases where it is preferable to mutate the input, you can also override how query results are compared for equality. As an example, an application may wish to attach prototypes to result data (for read-only helpers) - it would need to modify the equality check to deep compare the two results while ignoring prototypes. If the newly returned result (without prototypes) matches the data present in the previous result (with prototypes), Apollo would consider it a no-op and not trigger any changes.
nevir
force-pushed
the
result-transformation
branch
from
a39c9bc to
90df07e
Compare
…tion `resultTransformer` and `resultComparator`
|
@stubailo ping |
|
Merged! 🎉 Sorry it took so long. |
You can provide a
resultTransformerwhen configuringApolloClientto be able to modify query/mutation results immediately before they are returned to the application. Generally, transformers should avoid mutations of their input, as it will bust Apollo's result equality comparison (and cause unnecessary re-renders).For cases where it is preferable to mutate the input (performance), you can also override how query results are compared for equality via
resultComparator. This compares previously returned query results with newly fetched ones.As an example, an application may wish to attach prototypes to result data (for read-only helpers) - it would need to modify the equality check to deep compare the two results while ignoring prototypes. If the newly returned result (without prototypes) matches the data present in the previous result (with prototypes), Apollo would consider it a no-op and not trigger any changes.
This is a continuation of #378
Also, note that the prototype example is how we are currently using this transformer in our application